Reject queryType=semantic with 400 - #96

This PR is independent of #94, #95 and #97 (each branches off main), so it can be merged in any order. It is also the most optional of the four: it only turns a silent fallback to a plain query into a clear 400.

@daplein Thank you for the PR, but unfortunately I'm going to close it without merging.

I just filed issue #109 to replace this. In this case, since results might be somewhat usable running as a plain query, that is better than throwing a 400. Our emulator isn't intended to be a perfect nor production-grade app; instead it's to ensure that apps that use the Azure Search API can be usable locally without a cloud option. Unless the app depends on the @search.* outputs that semantic ranking adds, it should be usable today with the plain query fallback.

Thanks again, and I hope this doesn't discourage you from continuing to contribute to the project!

@daplein Thank you for the PR, but unfortunately I'm going to close it without merging.

I just filed issue #109 to replace this. In this case, since results might be somewhat usable running as a plain query, that is better than throwing a 400. Our emulator isn't intended to be a perfect nor production-grade app; instead it's to ensure that apps that use the Azure Search API can be usable locally without a cloud option. Unless the app depends on the @search.* outputs that semantic ranking adds, it should be usable today with the plain query fallback.

Thanks again, and I hope this doesn't discourage you from continuing to contribute to the project!

Thanks Paul, that makes complete sense. Agreed that a usable fallback fits the emulator’s goals better than a hard 400. And feature23/AzureSearchEmulator#110 is a much better outcome than my PR would have been. Real @search.rerankerScore/captions/answers is exactly what local testing needs. Thanks also for the quick turnaround on #94 and #95, and no worries at all about #97. feature23/AzureSearchEmulator#106 is a cleaner fix. Not discouraged in the slightest; happy to keep contributing.

@daplein Thanks for the response. 1.0.0-rc.1 adds the semantic re-ranker, and since you depend on that functionality, would you mind testing that to make sure it works for you? I'd like to make sure it's stable before we ship 1.0.0.

Note that to use the real ONNX model you'll have to follow the instructions in the README to enable that, otherwise it'll use a fake implementation.

@daplein Thanks for the response. 1.0.0-rc.1 adds the semantic re-ranker, and since you depend on that functionality, would you mind testing that to make sure it works for you? I'd like to make sure it's stable before we ship 1.0.0.

Note that to use the real ONNX model you'll have to follow the instructions in the README to enable that, otherwise it'll use a fake implementation.

Thanks Paul, tested it! Two parts:

1. Drop-in: I replaced the patched beta.4 image we’d been running with 1.0.0-rc.1, and our full integration suite passes against it, so no regressions for us.
2. Semantic reranker: I tried it directly with the ONNX model enabled and with the default ranker. With the model, “what is the capital of France” ranks Paris first (3.65) over the “capital” keyword matches, and returns extractive answers and captions with highlights. It also worked with filters, facets, semanticQuery and GET/POST, and gave clean 400s for a missing configuration or a bad answers value. The model downloaded and loaded in about 4 seconds, and queries took 15–55 ms. The default ranker returns the same response shape, which is all most local tests need.

One small thing I noticed: error responses have an empty "code" value, whereas Azure fills it in. Not a blocker for us.

Looks good for 1.0.0 from our side. Thanks for building this so quickly!